Exercice 1
singularity run docker://container/name| Virtual Machines | Container | |
|---|---|---|
| Guest OS | Each VM runs on virtual hardware and the kernel is loaded into its own memory region. | All containers share the same kernel. |
| Communication | Through Ethernet Devices. | Standard IPC mechanisms like Signals, pipes, sockets, etc. |
| Performance | Small overhead as the Machine instructions need to be translated from Guest to Host OS. | Near native performance as compared to the underlying Host OS. |
| Startup time | Takes up to a few minutes to boot up. | Containers can be booted up in a few seconds. |
| Isolation | Sharing libraries, files, etc. between guests and between guests and host not natively possible. | Subdirectories can be transparently mounted and can be shared. |
| Storage | VMs usually require more storage as the whole OS kernel and associated programs have to be installed and run. | Containers consume lower amount of storage since the Host OS is shared. |
For a detailed explanation, see Iván Moreno’s article on Medium
Singularity runs with the same user that starts the container while the Docker daemon runs as root.
Default Behavior: Docker isolates the container from the host machine by default. Singularity mounts the /home directory of the user running the container.
Side effects of mounting the home directory
All user customization files will be in the container when it runs. This can break the isolation/reproducibility concept, such as having user-defined R libraries.
It is recommended to run Singularity with –no-home or even with –containall (-C) and bind only the required directories.
You can create your own container image from ‘scratch,’ but normally you will start with an image that someone else has already created. To do so, you can either run the image straight from the external repository or download it locally and run it later.
When we run the container, it loads the image and executes the predefined command, if one is defined. Instead of running the predefined command, we can also open an interactive shell in the container.
Exercice 3
singularity shell local_image_name.sifexit )whoami-C option and verify that the home directory is empty.We can tell the container to run and execute a command with:
singularity exec local_image_name.sif command
Persistent changes
All changes made inside a container are lost when the container is stopped. If we need the changes to be persistent, we must use a folder from the host machine.
If we need to access files outside the container, we can “BIND” folders from the host machine to the container:
singularity shell -B /host/path:/path/in/container local_image_name.sif
Exercice 5
-C option (--containall).touch test.txt
“–fakeroot” or remote build
- Account for the resources needed by all the dependencies of your script.
- Do not run a container on the master node!
Exercice 7
sbatch to run the script and check the output. You can use squeue to see the progress. You will find the log file in the current folder when the job finishes.